Date: Fri, 25 Mar 94 04:30:19 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #81 

To: Ham-Digital 


Ham-Digital Digest Fri, 25 Mar 94 Volume 94 : Issue 81 


Today's Topics: 
(none) 
[REPOST] The # in PBBS addresses.... 
Baycom problem (2 msgs) 


FROM INTERNET 4597267@MCIMAIL.COM 
G-TOR 
Heathkit HD-4040 TNC 
HF Digital Throughput 
HP100LX Palmtop & Baycom? 
KPC-3 and TCPIP 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 24 Mar 94 14:15:52 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: (none) 

To: ham-digital@ucsd.edu 


unsub llakel@services.dese.state.mo.us 


THANK YOU for your help and reply 


0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/ 
10/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0 


% Lawrence (Larry) A. Lake * Lincoln County R-II School 
% 208 Redwood Drive * Industrial Technology Department 


% Elsberry, Missouri 63343 * Elsberry, Missouri 63343 % 


% Voice 314-898-5147 * Voice 314-898-2026 / 898-5553 % 
% E-mail llakel@services.dese.state.mo.us % 
% Packet kb@Qlco@kOpfx.#stl.mo.usa.na % 
% "Happiness is uniting your vocation with your avocation" % 


0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/ 
10/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0 


Date: 24 Mar 1994 04:54:23 GMT 

From: usc!howland.reston.ans.net! vixen.cso.uiuc.edu!newsrelay.iastate.edu! 
apollo1.cacd.cr.rockwell.com!zodiac.cca.cr.rockwell.com!newsfeed.ksu.ksu.edu! 
moe.ksu.ksu.edu!crcnis1.@@ihnp4.ucsd.edu 

Subject: [REPOST] The # in PBBS addresses.... 

To: ham-digital@ucsd.edu 


jangus@skyld.grendel.com (Jeffrey D. Angus) writes: 


>In article <YARBRDA.94Mar22162833@moose. gdss.grumman. com> 
yarbrda@moose. gdss.grumman.com writes: 


> > What's the significance of the # in certain PBBS addresses? I've seen 
> > them used with some places and not in others. For example, my own is 
> > 

> > ke4dxa @n41xi.#nova.va.us.noam. 

> A-- North America (Continental Code) 

> A----- United States (Country Code) 

> A-------- State or Province 

> AN------------- State sub-divisor (Area) 

> N------- ee eee ee Destination BBS 

> Newent oor es ini oie User 


the # symbol is an area designator. This way nova is not confused 
> with some other location. 


Slight correction to the above. The country code in packet radio is 
not us, it is usa. They are not the same and us is not acceptable at 
this time. There was talk at one time of using us, but it has not been 
adopted. On most systems that aren't wildcarded, us will become stuck. 


Gary 


Date: 24 Mar 1994 07:49:45 -0600 


From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!not-for-mail@network.ucsd.edu 
Subject: Baycom problem 
To: ham-digital@ucsd.edu 


I've just put together a Baycom modem. The transmit side works fine (tones are 
generated and the PTT triggers), but nothing seems to be received. I've traced 
the loudspeaker output through the modem chip and the 74HC14. The connection 
to the computer's CTS line is intact. My guess is that the computer's 8250 
just isn't able to do anything with the 5V signal the 74HC14 produces. This in 
itself wouldn't surprise me, but the documentation with the program suggests 
that this isn't normally a problem. But I've connected the board to three 
different PCs now, and none of them receives anything. Could it be something 
else? Or is signal level mismatch a more common problem than the documentation 
would have you think? 


Jim 


Jim Donnett VE3LXS/GOMVY 

Dept. of Anatomy and Developmental Biology 
University College London 

Gower Street, London, WC1E 6BT 

e-mail: donnett@anatomy.ucl.ac.uk 


Date: Thu, 24 Mar 1994 16:06:56 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu! 
news. csuohio. edu! sww@network.ucsd.edu 

Subject: Baycom problem 

To: ham-digital@ucsd.edu 


I just went through the same thing. Watch the CTS out line for data 
when the radio is unsquelched and white noise is being fed to the audio 
input. If you are getting data out to the CTS, plug one of those boxes 
with the LEDs onto the line. Do you see the data? 


I did. 
But I still did not have a response on the screen. 


Run DEBUG and use the command "i 3fe". If you are on a port with a 
base address of 3f8, 3fe will be the input status register. A change 
in the returned value will indicate a change since the last read. 

I could verify that CTS was working by manually toggling the port 
using a breakout box. So CTS worked. I was putting data to the CTS 


line and the computer was capable of reading it but I was not seeing it. 


The solution was in a 25 to 9 pin adapter. It was a "full" adapter, they 
said. Well, it wasn't. It was not carrying the CTS through. Three more 
25 to 9 adapters were the same way! My Logitech mouse plug adapter was 
the only 25 to 9 that carried the signal through. 


Good luck, 

73, 

Steve 
ag807@cleveland.freenet.edu 
NO8M.#NEOH.OH.USA.NA 


Date: 23 Mar 94 23:53:53 -0600 
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu! 
newsrelay.iastate.edu!cobra.uni.edu! parickj]4560@network.ucsd.edu 


To: ham-digital@ucsd.edu 


Does anyone own a Yaesu Ft 301???? I have one and I was wondering if anyone 
else had one. I guess they are very hard to come by. Also does anyone have 
any ideas on how much the radio and matching power suply would cost? My radio 
is in mint condition. 73's 


NOZYA temp AG Waterloo, Iowa 


Date: 24 Mar 94 14:55:00 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: FROM INTERNET 4597267@MCIMAIL.COM 
To: ham-digital@ucsd.edu 


HERE IS A LIST OF BOOKS ABOUT INTERNET AT WALDENBOOKS 
MOBILE, ALABAMA. 


WHOLE EARTH ONLINE ALMANAC - DON RITTNER 

ONLINE USERS ENCYCLO. - BERNARD ABBA 

CONNECTING TO THE INTERNET - AN O'REILLY BUYER'S GUIDE 
INTERNET: MAILING LISTS - EDWARD T. L. HARDIE /VIVIAN NEOU 
THE INTERNET RESOURCE QUICK REF. 

THE INTERNET NAVIGATOR - PAUL GILSTER 

NAVIGATING THE INTERNET - GIBBS AND SMITH 

THE INTERNET COMPANION - LAQUEY 

RIDING THE INTERNET HIGHWAY - SHARON FISHER 


OMON A OKRWN PR 


10. THE INTERNET ROADMAP - BENNETT FALK 

11. THE INTERNET YELLOW PAGES - HAHN AND STOUT 

12. THE WHOLE INTERNET USERS GUIDE AND CATALOG- ED KROL 

13. INTERNET: GETTING STARTED - APRIL MARINE/NEOU AND WARD 


I PURCHASED THE LAST BOOK. 

ALSO A GUIDEBOOK, ZEN AND THE ART OF THE INTERNET IS AVAILABLE 
ELECTRONICALLY, PLUS THERE IS A BOOK OUT BASED ON THE GUIDE, 
ZEN AND THE ART OF THE INTERNET: A BEGINNER'S GUIDE. BRENDAN 
KEHOE. THIRD EDITION JANUARY/1994. 


VIA N4SO KEN 4597267@MCIMAIL.COM 


NNNN 


Date: 24 Mar 94 19:50:00 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: G-TOR 

To: ham-digital@ucsd.edu 


Subject: Time:1:46 PM 
OFFICE MEMO G-TOR Date:3/24/94 
Copyright 1994, Kantronics Co., Inc. All Rights Reserved. G-TOR is a 
trademark of Kantronics Co., Inc. Permission granted by Kantronics to post 
on Ham-Digital newsgroup. 


G-TOR (tm) 
The New, Faster HF Digital Mode 
for the KAM-Plus 
by 
Phil Anderson (1), WOXI, Michael Huslig, 
Glenn Prescott, WBOSKX, and Karl Medcalf, WK5M 


On New Year's Day, WOXI and WK5M transmitted a 9,718 byte file from Kansas to 
WA4EGT (2) in California on 20-meters in 5 minutes, 20 seconds. The mode was 
G-TOR. Immediately thereafter, the file was transmitted again, this time 
using Pactor. It took 20 minutes, 15 seconds. Throughout the month of January 
these tests were repeated with over one-million bytes transferred error-free. 
The average character/second rate for G-TOR was 23.7, for Pactor 8.64 (3). 


G-TOR, short for Golay-TOR, is an innovation of Kantronics, Inc. It's a new 
HF digital communications mode for the amateur service based somewhat on 
concepts outlined in the MIL-STD-188-100 series of documents (4). The error 
correction coding outlined in 188-141A (ALE) forms the basis for G-TOR. In 
order to keep costs low yet take advantage of concepts prescribed in the 
standards, G-TOR makes use of existing multi-mode TNC hardware but 


establishes a completely new hybrid ARQ system in firmware. 
The benefits of these innovations are: 


o) dramatically increased throughput 


(o) apparent reduction in the effects of 
interference and multi-path 
(o) low cost 


The key features of G-TOR are: 


extended Golay forward error correction coding 

full-frame data interleaving 

on-demand Huffman data compression with run-length encoding 
link-quality based baud rate: 300, 200, or 100 

2.4 second hybrid-ARQ cycle 

fuzzy acknowledgements 

reduced overhead within data frames 

standard FSK tone pairs (mark and space) 


00O00000 0 


Background Research 


It occurred to us after porting Pactor into the KAM that this protocol did 
not go far enough. It did not incorporate any of the potential strengths 
prescribed by MIL-STD-188-141A. In addition, we knew that commercial and 
military systems use forward error correction (FEC) and data interleaving. 
So, we decided to evaluate the potential of using FEC coding with 
interleaving to increase data file transfer throughput with existing 
multi-mode TNCs such as the KAM and KAM-Plus. 


We collected signatures of HF error patterns by sending Pactor idle 
characters through a DSP-based HF simulator. The simulator was programmed for 
various types of channels and conditions. In particular, we gathered error 
signatures by using the good, moderate, poor, and flutter fading channels 
prescribed by the CCIR (5) as recommended simulator test channels. 


We then exclusive-ORed the error patterns with random data files on a PC and 
tested various coding schemes. Random data files were Golay encoded, 
interleaved, and then mutilated by the error signature. The process was then 
reversed; each file was de-interleaved, decoded and the data displayed. We 
were encouraged with the results so we moved on to the remaining major design 
tasks: designing a robust ARQ protocol and determining whether or not the TNC 
could handle the necessary computing task! 


Over several months we evolved a protocol that met the challenge. It was 
coded and ported into the KAM-Plus and real-time tests were conducted using 
the HF simulator. Minor adjustments were made - as in all projects - and we 
began on-the-air tests. Tests showed G-TOR to be even better than our 


simulator predicted. Through a combination of coding and interleaving, G-TOR 
‘hangs in there' when channel conditions get tough. 


G-TOR Frame Structure and ARQ Cycle 


G-TOR operates as a synchronous ARQ mode 1. Regardless of transmission rate, 
the cycle duration is always 2.4 seconds, data frames are 1.92 seconds long, 
and the acknowledgements take 0.16 seconds. At 300 baud, each data frame 
contains 69 bytes of data, one control byte, and a two byte CRC. At 200 baud 
the frame contains 45 data bytes, and at 100 baud 21 data bytes. 


Synchronization is established during the linking phase when the calling 
station (master) sends a G-TOR frame containing TO and FROM callsigns. The 
information receiving station (IRS), while in standby, synchronizes to the 
frame by searching for its callsign. Once in step, it acknowledges such to 
the master and sends <link established> to its terminal. Transmission of data 
may then begin. Sufficient time is left between the end of the data frame and 
the start of the acknowledgement for propagation between stations over an HF 
path. A change in information flow direction (changeover) is accomplished by 
extending the acknowledgement bytes into a changeover frame. Once 
acknowledged by the other station, changeover is complete. Link quality, 
dictated by the number of consecutive good or bad frames received, determines 
link speed. 


The effective performance of stations, while communicating over adverse HF 
channels, relies on the combined use of forward error correction, 
interleaving, and redundancy. These tools for improvement are incorporated in 
G-TOR within the firmware of the KAM-Plus (or KAM with enhancement board). We 
adopted an extended version of the (24,12) Golay code for G-TOR. 


Procedures for data formation, transmission, reception, and data recovery are 
outlined below. Prior to transmission, 300 baud frames are divided into 48 
12-bit words and matched with 48 error correction words of 12 bits each. The 
entire 72 byte data frame is then interleaved bit by bit, resulting in 12 
bins of 48 bits, and transmitted . Upon reception by the IRS, the reverse 
process is carried out. The frame is synchronized, de-interleaved, decoded, 
and checked for proper CRC. If the frame is found to be in error, the IRS 
will request that the matching parity frame be sent. Upon receipt, the parity 
frame is used in combination with the data frame in an attempt of recover 
the original data bits. If unsuccessful, the ARQ cycle begins again. The 
dispersement of noise-burst errors via interleaving and the power of the 
Golay code to correct 3 bits in every 24 usually results in the recovery of 
error-free frames. 


On-The-Air Testing 


During the month of January over a million bytes were transferred error-free 


from Lawrence, Kansas to Laguna Niguel, California. During these tests, TRACE 
was set ON at each station, enabling the display of acknowledgement bytes and 
data frames including control bytes. This allowed us to view and count data 
and acknowledgement frames received with and without the aid of forward error 
correction and interleaving. 


The results were somewhat surprising! While Pactor often dropped in 
transmission speed from 200 to 100 baud, G-TOR nearly always kept on 
crunching frames at 300 baud! Enough frames are corrected to keep the system 
running at 300 baud, regardless of man-made interference and mild multi-path 
conditions. This was apparent as G-TOR seldom dropped automatically from 300 
to 200 baud. Transfer duration for the entire test file varied from 12 to 27 
minutes for Pactor but only 5.5 to 7.5 minutes for all but one transfer in 
G-TOR. G-TOR simply maintained its highest pace better, resulting ina 
substantial increase in average throughput. 


Operation of G-TOR is much like AMTOR. You enter G-TOR standby by typing 
<GTOR> and <return> in response to the cmd: prompt. From standby you can copy 
AMTOR FEC (also used as the calling mode for G-TOR CQs), or wait for a G-TOR 
link request from another station. To initiate a link with another station, 
you must type <GTOR callsign return>. The link is then established and the 
TNC reports <linked to callsign>. During a QSO, changeover is dictated by the 
usual keyboard (or host-mode) directives, <control-C T> and <control-C E>. 


Conclusion 


G-TOR features include Golay forward error correction coding, full-frame 
interleaving, on-the-fly Huffman data compression with run-length encoding, 
fuzzy acknowledgments, a long ARQ cycle of 2.4 seconds, and a link-quality 
based transmission rate. Combined, these techniques result in a new, very 
robust, interference-resistant, and existing equipment compatible mode for HF 
digital communication for the amateur radio service. Throughput exceeds other 
existing all-mode TNC modes by better than two-to-one. G-TOR is not available 
for KAMs without the enhancement board since EPROM space has been used up. 
G-TOR is now standard in the KAM-Plus and the Enhancement Board for the KAM 
(predecessor of the KAM-Plus). 


1. Kantronics Inc., 1202 E 23rd Street, Lawrence, KS, 66046, 913-842-7745, 
fax 913-842-2021. 
2. Towle, Jeff, InterFlex Systems, PO Box 6418, Laguna Niguel,CA, 92607. 


3. Van Der Westhuizen, Mike, ZS6UP, "A Practical Comparison Between Clover 
and Pactor Data Transfer Rates," CQ, February, 1994. 


4. Military Standard (MIL-STD) series -188-100, containing standards common 
to long-haul communications, Department of Defense. Specifically 


MIL-STD-188-141A, Interoperability and Performance Standards for Medium and 
High Frequency Radio Equipment. 


5. Recommendations of the CCIR, 1990, Volume III. (Fixed Services at 
Frequencies Below About 30 Mhz), Recommendation 520-1, page 28. 


G-TOR is a trademark of Kantronics, Inc. 


Date: 24 Mar 94 21:32:44 MDT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!hellgate.utah.edu!cc.usu.edu! 
sltmw@network.ucsd.edu 

Subject: Heathkit HD-4040 TNC 

To: ham-digital@ucsd.edu 


In article <940321065400983@ctobbs.com>, kim.leong@ctobbs.com (Kim Leong) writes: 


I don't think my original post made it into this group so I'm 
re-posting. 


I have a Heathkit HD-4040 TNC that I built and had in service about 8 
years ago. I have been off packet for about 6 years. I dug the TNC out 
of its burial box and am interested in getting back on packet with it. 
The question I have is if there are some firmware or other updates 
anyone knows of that should or can be done to the HD-4040. 


Thanks, 
Kim Leong - WA6QQF 


BBS: “Sysop: @, (510): 799-2921 
Internet: kleong@ctobbs.com 


VVVV VV VV VV VV VV 


I use two HD-4040's...got ‘em for about 25 bucks each, and one has a TAPR TNC-2 
upgrade (DCD decoding too), and the other one has the WA7MBL firmware in it. 
They both work great! (I have the TNC-2 clone running KISS, and use JNOS) 


If you can get the upgrade, I would seriously consider it...Don't bother with 
the WA7MBL code (It is quality stuff, but no KISS mode) 


Daniel D Holmes - Marcel Marceau 

Internet: SLTMW@CC.USU.EDU 

AmprNet: N7NKR @ N7NKR.HOME.AMPR.ORG 44.40.1.43 [located in Salt Lake City] 
N7NKR @ N7NKR.AMPR.ORG 44.40.12.10 [located in Logan] 


Date: 24 Mar 94 20:04:07 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: HF Digital Throughput 
To: ham-digital@ucsd.edu 


Subject: Time:1:52 PM 

OFFICE MEMO HF Digital Throughput Date:3/24/94 

Based on published test data, here is my reading on the typical throughput 
(characters per second) to be expected from several HF digital modes: 


RTTY 6 
AMTOR (ARQ) 5 
Packet AX.25 4 
PacTOR 10 
G-TOR 25 
CLOVER II 50 


Note that Huffman data compression is available in the PacTOR and G-TOR 
protocols to increase throughput for certain data. Note also, that these 
throughputs are not normalized to occupied bandwidth. If one looks at 
characters per second per hertz there are even more dramatic differences. 


73/Rick WOTN <rick_whiting@atk.com> 


Date: Thu, 24 Mar 1994 16:24:28 GMT 

From: ihnp4.ucsd.edu! galaxy.ucr.edu!library.ucla.edu!agate!usenet.ins.cwru.edu! 
news.csuohio. edu! sww@network.ucsd.edu 

Subject: HP10OLX Palmtop & Baycom? 

To: ham-digital@ucsd.edu 


Steve Wolf (sww@csuohio.edu) wrote: 


: Has anyone been able to get Baycom to work on the Hewlett Packard 
: 100LX palmtop? After externally powering the Baycom, I was able 
: to transmit readable packets. However, it does not appear that 

: the HP is reading the CTS line. I have verified that data is 

: going to the CTS out. 


: There is a pretty good user support group on comp.palmtops and HP 
: seems interested in any application it can be put to. I wanted to 
: check here first. 


: Also, the paltop runs the MSYS BBS without a complaint. Running with 
: 300 message slots and about 500 BIDs left me over 150k free (so I could 
: make lots more slots and BID space). 


: Interesting that a 80188-based machine can run the serial port at 
: 57k yet we have to watch our BBS phone ports for dropped characters. 


173); 

: Steve 
ag807@clevland.freenet.edu < works better 
NO8M@NO8M.4#NEOH.OH.USA.NA 


The solution to this problem was not easy. I verified that 
the HP was seeing CTS (through reading the status register) and 
that the Baycom was sending information through a meter. 

It turned out that a problem I had before came back. A 
9 to 25 adapter did not carry the signal through. Three of them 
didn't. Only the Logitech adapter for my mouse worked. I now 
have those marked as problems. 


73, 

Steve 
ag807@cleveland.freenet.edu 
NO8M@NO8M.#4NEOH.OH.USA.NA 


Date: 23 Mar 94 23:07:52 GMT 

From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!nic.scruz.net!cruzio! 
comix! jeffl@network.ucsd.edu 

Subject: KPC-3 and TCPIP 

To: ham-digital@ucsd.edu 


In article <dparkerCn314q.AQM@netcom.com> dparker@netcom.com (Dave Parker) writes: 
>One thing to consider is there is no upgrade for 9600 bps on this 

>TNC, look at the DRSI DPK-2 at least it has a modem disconnect 

>header so you can use an external high speed modem later if you wish. 

>Its priced roughly in the same ballpark as the KPC-3. 

>Dave, KD6RRS 


This is a plug. I just bought an AEA PK-96. This is a new TNC. 
It's a combination AFSK (1200 baud) and FSK (9600 baud G3RUH) tnc. 
In theory, you can have it all in one package. No ripping out 
the disconnect header every time you switch. I overpaid at $190 
but am not complaining. It draws 400ma at 13.6v (3.5w) so it's 
not exactly suitable for battery operation. Too soon to tell if 


it's any good. Anyway, it is possible to buy a TNC that will do 
both 1200 and 9600. IMHO, tcp/ip should be run at 9600 and not 
1200. It's just too slow. 


d# Jef£ Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 
dF 408.336.2558 voice wbé6éssy@ki6eh.#nocal.ca.usa wb6ssy.ampr.org [44.4.18.10] 
# 408.699.0483 digital_pager 73557,2074 cis [don't] 

d# jeff1@comix.santa-cruz.ca.usS scruz.ucsc.edu!comix! jeff1l 


Date: 24 Mar 1994 15:49:04 GMT 

From: ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!ncar!csn!col.hp.com! 
jms@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <2mksi3$mal@crl.crl.com>, <2mnbtp$sr7@hpbab.mentorg.com>, 
<1994Mar23 .180631.11120@mnemosyne.cs.du.edu>2,, 
Subject : Re: KPC-3 and TCPIP 


: >KPC-3 is excellent value for the money. 

: If you only want to go 1200 baud it's fine and if you want to keep the same 
: EPROM in it it's fine. But if you ever want to modify it for high speed 

: or DCD or KISS only you'll regret buying as I did. 


: Just my opinion and expierience, 
: 73, Nate 


The KPC-3 already has KISS capability. 
Mike, KOTER 


End of Ham-Digital Digest V94 #81 
KKKKKKKKKKKKKKKKKKKKKKKKKRKE KAKA 


